Docs: split builtins to their own page from library - #156682
Conversation
37b2ad3 to
10c84e6
Compare
|
Also: is this NEWS-worthy? |
I don't see a need for one here, I think the docs speak for themselves. |
Documentation build overview
72 files changed ·
|
hugovk
left a comment
There was a problem hiding this comment.
Shall we name the new Doc/library/builtin-index.rst as Doc/builtins/index.rst instead?
Then instead of:
We get a neater:
This PR can still reference the builtin stuff in their current location, and a followup could move the relevant files and deal with redirects:
- Doc/library/functions.rst -> Doc/builtins/functions.rst
- Doc/library/stdtypes.rst -> Doc/builtins/stdtypes.rst
- Doc/library/constants.rst -> Doc/builtins/constants.rst
- Doc/library/exceptions.rst -> Doc/builtins/exceptions.rst
- Doc/library/threadsafety.rst -> Doc/builtins/threadsafety.rst
- Doc/library/time-complexity.rst -> Doc/builtins/time-complexity.rst
StanFromIreland
left a comment
There was a problem hiding this comment.
Also, you need to update the What Now? page in the tutorial.
I concur with Hugo, splitting this into a separate directory would be nicer. We can do redirects at client side (using one of the various Sphinx extensions) or sever side (by configuring them in python/psf-salt).
|
I can do the renames and redirects.
What Sphinx extension have we used for redirects before? I see https://github.com/python/psf-salt/blob/main/salt/docs/config/nginx.docs-redirects.conf for the psf-salt approach. |
We use |
I knew rediraffe was somewhere! Is there a reason we don't want to introduce it for the main docs? |
I presume it's simply because there hasn't really been a need so far. We're less keen to move pages here than in the Devguide. IIRC rediraffe requires JS, but that ship has sailed anyway. |
|
Server-side psf-salt redirects would be better than client-side sphinxext-rediraffe: they work with JavaScript disabled (better for all the scrapers and bots), are faster on server-side (HTTP layer before any HTML fetched), and get cached in the CDN, and better for SEO. We don't have such server-side control for the devguide, which is hosted on GitHub Pages. (Also I'd say client-side JS redirects are fine for the less-important devguide.) |
|
That all makes sense. Do we have a way to coordinate the updates to psf-salt with updates to the docs, especially with backports involved? |
|
(There's no documented process I'm afraid) You can open a PR there and limit the redirect to specific Python versions. I can review and merge when we land this. |
c6de373 to
ea9966e
Compare
|
Moving pages causes the "removed HTML IDs" check to fail. The IDs aren't gone, they are in a different page. Do I still add them to removed-ids.txt? |
Yes, see the line with an asyncio file for the required format. |
5219e72 to
373f4e6
Compare
|
I've updated the id checker to follow redirect files. |
BTW, the rediraffe stubs do not depend on JavaScript, it uses two techniques: though the JavaScript half will keep the anchor and query string. |
|
There are conflicts now. Also, a few additional sites that need updating: |
65aaf8b to
016ce6b
Compare
|
I think this is done. |
|
sorry, a habit from other repos. |
| learning about random subjects, you choose a random page | ||
| and read a section or two. Regardless of the order in which you | ||
| read the sections of this manual, it helps to first read | ||
| :ref:`built-in-funcs` in :ref:`builtins-index`, as the remainder of this section |
There was a problem hiding this comment.
Is the second link required, if the first one already brings the reader to the right page?
(This reads to me like «Read Section A in Chapter 1», which is needed in books but not hypertext)
|
|
||
| .. seealso:: | ||
|
|
||
| Let the show begin! |
There was a problem hiding this comment.
Wasn’t this was harmless and a bit of flair?
| browse the table of contents (in front of the manual), or look for a specific | ||
| function, module or term in the index (in the back). And finally, if you enjoy | ||
| learning about random subjects, you choose a random page number (see module | ||
| :mod:`random`) and read a section or two. Regardless of the order in which you |
There was a problem hiding this comment.
Why not keep the random module link as an example of a random page? (and/or maybe a hint about a way to make random decision!)
Not fully sure what the original intent was here, but as we are in Library Reference and not Tutorial I don’t think the link was bad. Can you say why you removed it?
| in to the Python interpreter; others are written in Python and imported in | ||
| The Python standard library consists of a collection of modules. There are | ||
| many ways to dissect this collection. Some modules are written in C and compiled | ||
| into the Python interpreter; others are written in Python and imported in |
There was a problem hiding this comment.
Should we say that some modules are written in C and compiled to importable modules, or is it confusing at this point?
| self.__ids.add(value) | ||
|
|
||
|
|
||
| def get_ids_from_file(path): |
There was a problem hiding this comment.
Consider avoiding some duplicate work here:
| @functools.cache | |
| def get_ids_from_file(path): |
We've talked about separating the built-ins from the stdlib modules, since "dict" (for example) isn't part of the stdlib.
I think I took care of all the places the pages are referenced, but the non-HTML builds are new to me, so I might have missed something.
I tried to make the intro paragraphs and pages useful, and avoided over-editing them.